项目进入集中测试和缺陷跟踪阶段后，ALM Soft里往往已经积累了需求、测试用例、执行记录和缺陷等数据。到了阶段汇报、数据核对或者项目交接时，这些内容经常需要导出到Excel等文件中继续整理。问题也容易出现在这里，有时页面中明明能看到完整记录，导出的表格却少了测试步骤、部分字段没有出现，或者经过筛选后只留下当前页面中的数据。ALM Soft不同模块的导出范围并不完全相同，处理这类情况时，要先分清准备导出的数据属于哪个模块，再选择对应方式。

开发说问题修好了，测试却不知道该找谁复测；缺陷明明没有通过验证，状态已经变成“已关闭”。碰到这种情况，先把状态怎么走、由谁来改说清楚，再检查系统里的规则。本文围绕“ALM Soft怎么设置缺陷跟踪规则ALM Soft缺陷状态更新失败如何检查”展开。ALM是应用程序生命周期管理的行业概念，文中的状态和入口按常见测试管理流程说明，具体菜单请以正在使用的平台为准。

需求说明改了三次，测试人员看的却还是第一版；项目群里能打开文档，换到系统里又提示没有权限。项目文档一多，类似的小麻烦很容易拖慢协作。围绕“ALM Soft怎么管理项目文档ALM Soft项目文档权限异常如何调整”，下面按整理文档、分配访问范围和排查异常来操作。ALM是应用程序生命周期管理的行业概念，不同平台的按钮名称会有差异，步骤中的界面入口需与当前使用的软件对应。

测试项目进入用例设计阶段后，测试计划通常用来整理测试范围、用例结构以及需求对应关系。项目规模变大以后，如果测试内容只是零散记录，后面安排执行、查看覆盖情况时很容易混乱。ALM Soft一类测试管理工具会把测试计划、测试用例和需求信息放在同一项目中管理，不过创建目录只是基础，真正使用时还可能遇到用例关联不上需求、目标对象找不到、保存后关系没有保留下来等情况，这些都需要结合当前项目状态判断。

ALM Soft覆盖需求、开发、测试和部署等环节，需求流程则决定一项需求由谁接收、何时评审，以及怎样进入开发和验收。本文以Jira Cloud的公司管理型项目为操作示例，说明ALM Soft怎么配置需求管理流程ALM Soft需求流程配置后状态无法流转如何排查。不同ALM平台的菜单名称可能不同，操作时请以当前产品界面为准。

ALM Soft里的缺陷管理和测试执行是连在一起的。测试人员执行用例时，如果结果未通过，可以直接从当前执行记录提交缺陷，这样缺陷会自动带上对应的用例关系；也可以进入缺陷视图单独新建缺陷，再补充关联信息。实际使用里，最容易碰到的问题是缺陷已经创建成功，但回头看测试用例时没有关联记录，或者在缺陷详情里找不到原来的执行用例。这类情况要先分清缺陷是从哪里提交的，再检查用例有没有进入测试轮次、是否已经执行，以及提交缺陷时有没有带上关联用例。

ALM Soft里的需求审批主要用来把需求提交、评审、通过或退回这些动作串成固定流程，避免需求还没确认就直接进入后面的研发阶段。流程本身可以调整，审批节点也可以指定给项目角色、具体用户或组织角色。状态卡住时，很多问题并不是需求内容本身有错，而是节点没有处理人、项目成员缺少对应角色，或者上一节点没有真正提交完成。

版本发布规划做得太粗，常见结果就是需求临时插入、测试时间被压缩，正式上线后又冒出一批没人认领的问题。处理“ALM Soft版本发布怎么规划ALM Soft版本发布后的遗留问题如何管理”，需要把需求、迭代、测试、缺陷和发布版本关联起来，让每一项工作都有明确状态和后续去向。

研发过程中遇到需求调整、缺陷修复或版本范围变化，通常都要先提交变更请求，再进入影响评估和审批。ALM Soft的具体字段可能经过企业定制，但整体思路差不多：把改什么、为什么改、影响多大和怎么回退写清楚，审批人才能快速判断。

在ALM Soft这种项目管理工具里面，权限角色的设置要是很不明确，就非常容易导致两种状况发生，一种是普通成员被给的权限过大，导致需求、测试用例还有缺陷被他们随意改动，另一种是权限被给得太少了，用户在登录之后居然连项目都瞧不见，虽然权限管理这件事情表面上是由管理员来负责的，但是项目协作的过程会直接被它影响到，特别是在多人共同去参与需求、开发、测试以及缺陷处理的时候，角色的分配必须提前去做好规划，可不能等问题真的发生了才去临时修补权限。